feat: binary HID-RPC wheel dispatch#1462
Open
mcuelenaere wants to merge 3 commits into
Open
Conversation
adamshiervani
requested changes
May 18, 2026
| if (rpcHidReady) { | ||
| reportWheelEvent(wheelY, wheelX); | ||
| } else { | ||
| // kept for backward compatibility |
Contributor
There was a problem hiding this comment.
No need to be backwards compatible nowadays. The Cloud SPA is versioned, and the LAN access always serves a matching Go API and JS SPA.
Please remove the wheelReport code path.
Contributor
Author
There was a problem hiding this comment.
Addressed in a5f197b — dropped the JSON-RPC fallback in getMouseWheelHandler and removed the wheelReport entry from the JSON-RPC handler map. Binary 0x04 is now the only path; rpcWheelReport stays but is reached only via handleHidRPCMessage.
mcuelenaere
added a commit
to mcuelenaere/kvm
that referenced
this pull request
May 18, 2026
Per PR review (jetkvm#1462): the Cloud SPA is versioned and LAN access always serves a matching Go API and JS SPA, so the backwards-compat fallback is unnecessary. Drop the `rpcHidReady ? binary : send(...)` branch from getMouseWheelHandler — always use the binary path — and remove the `wheelReport` entry from the JSON-RPC handler map. The binary 0x04 dispatch and rpcWheelReport itself stay; the function is now reached only via handleHidRPCMessage. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
mcuelenaere
added a commit
to mcuelenaere/kvm
that referenced
this pull request
May 26, 2026
Per PR review (jetkvm#1462): the Cloud SPA is versioned and LAN access always serves a matching Go API and JS SPA, so the backwards-compat fallback is unnecessary. Drop the `rpcHidReady ? binary : send(...)` branch from getMouseWheelHandler — always use the binary path — and remove the `wheelReport` entry from the JSON-RPC handler map. The binary 0x04 dispatch and rpcWheelReport itself stay; the function is now reached only via handleHidRPCMessage. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
a5f197b to
4992aaa
Compare
The wheel opcode and its queue routing were already in place, but handleHidRPCMessage had no case for it, so binary wheel frames hit the default warn-log arm and were silently dropped. Wheel input had to take the JSON-RPC slow path, paying a per-event encode/parse on the ARM and foregoing the unreliable-ordered transport mouse motion already uses. Add a length-strict WheelReport decoder (Y-only, 1-byte payload) and route 0x04 through the same rpcWheelReport backend the JSON-RPC handler uses. The JSON-RPC path is unchanged so old clients keep working. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Mirror the existing rel/abs mouse pattern: when the HID-RPC binary channel is ready, send a WheelReportMessage (0x04) over the unreliable-ordered channel instead of the wheelReport JSON-RPC call. Falls back to JSON-RPC during the WebRTC/handshake window or against older firmware that does not dispatch the binary opcode. Also fix two pre-existing oxlint warnings in the same files (restrict-template-expressions) forced by lint-staged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Per PR review (jetkvm#1462): the Cloud SPA is versioned and LAN access always serves a matching Go API and JS SPA, so the backwards-compat fallback is unnecessary. Drop the `rpcHidReady ? binary : send(...)` branch from getMouseWheelHandler — always use the binary path — and remove the `wheelReport` entry from the JSON-RPC handler map. The binary 0x04 dispatch and rpcWheelReport itself stay; the function is now reached only via handleHidRPCMessage. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
4992aaa to
a395b66
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Wires the
TypeWheelReport(0x04) binary HID-RPC opcode into firmware dispatch and updates the browser frontend to use it when the HID-RPC channel is ready. The opcode and queue routing already existed ininternal/hidrpc/hidrpc.go, buthandleHidRPCMessagehad nocasefor it, so binary wheel frames hit the default arm and were silently dropped. Wheel input had to take the JSON-RPC slow path.Now wheel rides
hidrpc-unreliable-orderedlike mouse motion: per-event JSON encode/parse is gone, latency drops on the ARM, and the binary path matches the existing mouse/keyboard pattern. Wire format is[0x04][deltaY: int8][deltaX: int8]— both axes carried.Two commits:
feat(hidrpc): dispatch binary TypeWheelReport (0x04) frames— length-strictWheelReportdecoder, dispatch case inhandleHidRPCMessage, 10 table-driven test cases.feat(ui): send mouse wheel via binary HID-RPC when available— newWheelReportMessageclass,reportWheelEventhook,getMouseWheelHandlerswitches torpcHidReady ? binary : send(\"wheelReport\", ...)matching the rel/abs mouse pattern.The JSON-RPC
wheelReportmethod is unchanged; old clients and the transient WebRTC/handshake window keep working.Checklist
Note
Medium Risk
Changes the end-to-end mouse wheel input path (new binary opcode handling in Go + new frontend message), which could affect scroll behavior/latency if the wire format or channel selection is wrong; fallback to existing JSON-RPC reduces blast radius.
Overview
Enables mouse wheel events to flow over the binary HID-RPC channel by adding
TypeWheelReporthandling in the Go dispatcher and a strictWheelReportdecoder (with new unit tests) ininternal/hidrpc/message.go.Updates the UI to emit wheel input as a new
WheelReportMessageover the unreliable-ordered HID-RPC data channel whenrpcHidReady, while keeping the existing JSON-RPCwheelReportpath as a backward-compatible fallback. Also tightens a macro marshal error message and logs RTC channel errors usinge.type.Reviewed by Cursor Bugbot for commit a5f6d70. Bugbot is set up for automated code reviews on this repo. Configure here.